Montar PostgreSQL con pgvector es, a comienzos de 2024, la forma más sensata de arrancar un proyecto RAG sin introducir una base nueva. Esta guía describe una instalación reproducible sobre Debian 12 o Ubuntu 22.04 a 24.04 con PostgreSQL 16 y pgvector 0.6, operando con las mismas herramientas que ya dominamos: pg_dump, pg_basebackup, pg_stat_statements y réplicas.
Por qué pgvector y no una base vectorial dedicada
La tentación de elegir Pinecone, Weaviate, Milvus o Qdrant es natural cuando uno empieza a leer sobre embeddings. Todas son soluciones competentes, pero introducen un sistema nuevo que hay que desplegar, respaldar, monitorizar y aprender. Para volúmenes por debajo de cincuenta millones de vectores y cargas que mezclan búsqueda semántica con filtros relacionales, pgvector suele ser la decisión económicamente correcta: aprovecha transacciones, joins, índices GIN sobre JSONB y réplicas de lectura ya domadas.
La contrapartida honesta es que pgvector no compite en rendimiento puro con motores escritos expresamente para vectores, ni en funcionalidades como cuantización por producto o filtrado híbrido nativo. Si la aplicación vive y muere por la latencia sobre cientos de millones de documentos, conviene reevaluar. Hasta ese umbral, tener un único sistema que el equipo sabe operar paga dividendos cada vez que toca restaurar un backup a las tres de la mañana.
Repositorio oficial PGDG
Las versiones de PostgreSQL de las distribuciones suelen ir por detrás de la rama estable. El repositorio PGDG del propio proyecto es la ruta recomendada porque ofrece PostgreSQL 16 junto con postgresql-16-pgvector actualizado y permite que convivan varias versiones mayores en la misma máquina. El procedimiento estándar instala curl, ca-certificates y gnupg, descarga la clave ACCC4CF8, añade la línea PGDG apropiada en sources.list.d y refresca con apt update; apt install postgresql-16 postgresql-client-16 deja el servidor listo con la unidad systemd postgresql@16-main.service.
Instalación de pgvector
Hay dos caminos razonables. El paquete postgresql-16-pgvector de PGDG trae la última versión publicada (0.6 en febrero de 2024) y es la opción por defecto. Si necesitamos una build concreta o aplicar un parche, compilamos clonando el repositorio y ejecutando make && make install. A diferencia de otras extensiones, pgvector no requiere shared_preload_libraries: basta con CREATE EXTENSION vector dentro de cada base de datos donde vayamos a usarla, porque la extensión es por base, no global al clúster.
Usuario, base de datos y extensión
Nunca debe usarse el rol postgres para la aplicación. Creamos un rol dedicado, por ejemplo ragapp, con contraseña fuerte generada por un gestor, y una base ragdb cuya propiedad le asignamos. Dentro de esa base ejecutamos CREATE EXTENSION IF NOT EXISTS vector y concedemos permisos sobre el esquema public. Una consulta a pg_extension debería devolver 0.6.0, que sirve como primera verificación de que binario y catálogo están en línea.
Configuración mínima de producción
Los valores por defecto de PostgreSQL son conservadores para no bloquear instalaciones en equipos modestos. En una máquina con dieciséis gigabytes dedicados a la base merece la pena reajustar cuatro parámetros clave en postgresql.conf:
shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 64MB
maintenance_work_mem = 512MB
wal_level = replica
max_wal_size = 4GB
max_connections = 100La regla práctica sitúa shared_buffers cerca del veinticinco por ciento de la memoria y effective_cache_size en torno al setenta y cinco, dejando work_mem moderado porque se multiplica por conexiones y por operaciones dentro de cada consulta. Sesenta y cuatro megabytes con cien conexiones y dos operaciones rondan los trece gigabytes teóricos, así que conviene medir antes de subirlo. maintenance_work_mem importa especialmente porque CREATE INDEX sobre HNSW lo consume sin pudor.
IVFFlat frente a HNSW
Pgvector ofrece dos estructuras de índice aproximado. IVFFlat, más antiguo y maduro, particiona el espacio en listas y exige ejecutar ANALYZE tras cargar datos representativos para que el planificador elija bien; funciona razonablemente con unos pocos millones de vectores y consume poca memoria. HNSW, incorporado en la versión 0.5 y ya estable en 0.6, construye un grafo jerárquico que ofrece mejor relación precisión-latencia a costa de tiempos de construcción y memoria mayores.
La recomendación pragmática para 2024 es empezar con HNSW usando los parámetros por defecto (m = 16, ef_construction = 64), porque en la mayoría de casos la calidad supera a IVFFlat sin necesidad de calibrar listas. Si el conjunto supera unas decenas de millones de filas o la ventana de mantenimiento no tolera reconstrucciones largas, IVFFlat con lists ajustado a la raíz cuadrada del número de filas puede ser más apropiado. Construirlo en tabla vacía cuesta microsegundos; hacerlo sobre millones de filas tarda horas y satura CPU y entrada/salida.
Esquema típico y operadores de distancia
Un esquema canónico para RAG combina un identificador, el texto original, metadatos en JSONB para filtros y una columna embedding vector(1536) si usamos modelos de OpenAI. El índice GIN sobre metadatos acelera filtros por etiquetas, mientras que el índice HNSW sobre la columna vectorial con vector_cosine_ops habilita el operador <=> para distancia coseno. Pgvector también expone <-> para euclídea y <#> para producto interno negado; la elección depende del modelo, y con OpenAI lo correcto es coseno porque sus vectores ya vienen normalizados. Mezclar operadores con vectores no normalizados es la fuente más frecuente de resultados raros que luego uno achaca al índice.
Acceso, backup y observabilidad
Por defecto el servidor escucha en localhost y así debe quedarse salvo que la aplicación resida en otro nodo. En ese caso abrimos listen_addresses a la interfaz privada necesaria y añadimos una línea en pg_hba.conf que limite el rango y exija scram-sha-256. Exponer PostgreSQL directamente a Internet es un error: un túnel SSH o una VPN son siempre preferibles. Para backup, pg_dump -Fc -Z9 sirve el día uno, pero cuando la base crece conviene adoptar pgbackrest o restic con rotaciones incrementales y probar la restauración periódicamente; un backup sin prueba de restore es una expectativa, no una garantía. La observabilidad mínima exige habilitar pg_stat_statements, vigilar que el ratio de aciertos del buffer cache supere el noventa y nueve por ciento y exportar métricas con postgres_exporter hacia Prometheus. Los índices HNSW degradan si el autovacuum no acompaña.
Conclusión
Instalar PostgreSQL con pgvector no es complicado, pero cada decisión importa más de lo que parece. La elección del repositorio PGDG, el rol dedicado, la extensión creada en la base correcta, el índice HNSW construido en el momento adecuado y el maintenance_work_mem suficiente para que esa construcción no se eternice son la diferencia entre un despliegue que envejece bien y uno que exige intervención cada pocas semanas.
El argumento para usar pgvector frente a alternativas dedicadas es operativo más que técnico. Pocas organizaciones se benefician de introducir una base específica para vectores cuando ya operan PostgreSQL con soltura; la mayoría encuentra que el ahorro aparente en rendimiento se paga con creces en complejidad de backup, réplicas y monitorización duplicadas. Cuando llegue el momento de migrar a un motor especializado, el punto de partida será una base ya en producción con su corpus de embeddings, no una hoja en blanco, y eso hace que postergar la migración sea casi siempre la decisión correcta.
